It is desirable to have an understanding of software for software development, improvement, and maintenance. For this reason, it is desirable to divide software into small scale subsets that are easily understood. Software division is discussed in detail. Furthermore, the elements that structure software are termed as “entities.” For example, components, modules, source code, classes, functions, databases, files, and the like correspond to entities.
Also, relationships such as call relationships, inheritance relationships, inclusive relationships, data access relationships, and the like are termed as “dependent relationships” between entities. Entities in the software may be expressed with directed graph configurations (hereafter, abbreviated to “graph”) as vertices, using relationships between entities as directed edges (hereafter, abbreviated to “edges”). Software division is the division of graphs into subgraphs. Subgraphs include sets of entities.
There has been many proposals of software division technologies of the related art for uses other than the understanding of software. For example, Japanese Laid-open Patent Publication No. 2003-308216, which is an example of related art, discusses a technology to divide software into small structural elements and load only those elements desired in order to decrease the amount of memory usage of software loaded into memory space.
Also, there are proposals of technologies that perform automatic software division to reduce the work of creating desired information for division. For example, Japanese Laid-open Patent Publication No. 2009-134379, which is an example of related art, discusses a technology to divide software into multiple groups in order to decrease the amount of memory usage of software loaded into memory space, in regards to software that operates by combinations of multiple software modules. Japanese Laid-open Patent Publication No. 2009-134379 discuses representing a strength of dependent relationships between modules as the number of call points, and performing automatic division by dividing software to suppress this strength. In other words, the automatic division of Japanese Laid-open Patent Publication No. 2009-134379 streamlines the loading of software into memory by not dividing and aggregating modules that have a high frequency of call relationships.
Also, the general problem with software division is the inability to apply automatic division methods correlated with some specific purpose to a different purpose, as the desired type of division changes depending on the purpose of the division. Accordingly, methods are discussed that allow an individual to edit a division process and adapt it to their purposes, as the desired division changes depending on the purpose of analysis. For example, “Software Architecture Reconstruction: A Process-Oriented Taxonomy” by S. Ducasse and D. Pollet, IEEE Transactions on Software Engineering, vol. 35, no. 4, pp. 573-591, 2009 is an example of this kind of related art. Also, “Supporting Migration to Services using Software Architecture Reconstruction” by L. O'Brien, D. Smith, and G. Lewis, 13th IEEE International Workshop on Software Technology and Engineering Practice (Step '05), pp. 81-91, 2005 is another example of this kind of related art.
Also, as an aid to the understanding of software, it is desired that the software division is applicable to the work, functions, and tasks that express the software. Here, these functions, tasks, and work are referred to as “roles.” Software design takes place by extracting, organizing, and compartmentalizing the roles to be fulfilled by the software. As the understanding of software is the reverse progression of this design process, extracting and analyzing the roles is a key to the understanding of software.
The following conditions (1) and (2) are used to determine if a subset of a divided entity follows a role. (1) The inter-entity dependent relationship and an important entity which functions as the main purpose that represents the role implied by the subset are both included in this subset. (2) The inter-entity dependent relationship and trivial detail entity which hinders understanding of the main purpose of the software are disregarded when this subset forms.
An example technology to remove the “inter-entity dependent relationship and trivial detail entity which hinders understanding of the main purpose of the software” as described above is discussed in non-patent literature below. For example, “Summarizing the Content of Large Traces to Facilitate the Understanding of the Behavior of a Software System” by A. Hamou-Lhadj and T. Lethbridge, 14th International Conference on Program Comprehension (ICPC '06), pp. 181-190, 2006, which is an example of related art, refers to ubiquitous functions in software such as log processing and exception processing as “utilities”, and reduces noise interfering with the understanding by removing call relationships of utilities.